working from home...

[whit3rd]

On Thursday, July 30, 2020 at 10:03:22 AM UTC-7, jla...@highlandsniptechnology.com wrote:

On Thu, 30 Jul 2020 08:40:32 -0700 (PDT), whit3rd <whit3rd@gmail.com
wrote:

There\'s international agreement on how the WHO reports are handled,
but local quirks make most data questionable for a variety of reasons (mainly
just innocent).

In recent weeks, SF has had very odd infection/death ratios, completely
unlikely and out of sync with the rest of the nation. Why?

SF\'s PPM death count is very low. Maybe it\'s the climate, cool with
very high humidity.

Oh, pull the other one! The climate for a virus is about 98,6 Fahrenheit and
one hundred percent humidity. This is about INFECTIONS that do happen,
and DEATHS that do not.

The count is very low, and there IS some kind of reason, but while a climate
might affect transmission rate, that\'s clearly not what causes low death
probability.

 

[Martin Brown]

On 30/07/2020 21:29, Joerg wrote:

On 2020-07-30 05:38, Martin Brown wrote:
On 29/07/2020 19:29, Joerg wrote:

I notice that problem only when overseas parties are participating,
hardly ever with anyone is on the US West Coast.

I do see pings that are *much* slower to the US West coast than into the
East Coast or Chicago but the congestion is internal to the USA. You
just may be unlucky in your choice of European country or city but
German telecoms infrastructure should be OK.

For example, I just pinged my old health care provideer in Europe for
a test, 171-175msec. It is a very large company with good IT
infrastructure. Pinging Intel in California results in 12-17msec.

Try pinging somewhere physically on the US East coast and I expect you
will find >100ms delays to there too. Weirdly I just tried pinging
UCSD.edu and to my surprise got a 55ms ping response.

Large corporations and universities often have \"mirror\" servers in more
than one continent. The problem arises when they don\'t. It often depends

Yes. Looks like they have something in London then.

on where in the world you are. For example, to Japan I get 110-120msec
and it\'s probably more for you in the UK. Try pinging
http://ikuta-sanki.com, for example.

290ms +/- 2ms so reproducible but quite a high delay but it is half way
round the world from here.

                                              ... We do on occasion
have bandwidth issues which are also local problems.  I don\'t turn on
my video because of my Internet connection being poor in both latency
and bandwidth.

See? That\'s what I mean. IME the audio latency does not improve when
turning off the video. That we only do when the bandwidth on the other
side is too skimpy.

The audio quality sometimes goes haywire though with video on. Sort of
like a motorboat effect.

They should always, always prioritize audio over video. Video without
audio is typically useless. Audio without video allows the conference to
go on.

Indeed. Video freezes first when the thing stalls or is about to stall.

--
Regards,
Martin Brown

 

[Jeroen Belleman]

On 2020-07-30 22:16, Joerg wrote:

On 2020-07-29 21:40, Joe Chisolm wrote:
[...]

ITU says 150ms one way, so called \"mouth to ear\". Cisco says that
can be pushed to a 200ms budget. Also > 30ms packet jitter can be
a problem. If you examine the video you normally see very little
movement with a conference. Some static power point slide while
people talk. Even video of people talking the back ground is very
static. Frame to frame compression can be very high, thus video
can be good but audio is poor.


Problem is, even with only 150msec it can take up to a 1/3rd of a
second (rount trip) to realize that the other guy must have started
talking at the same time. Then we both stop, both start again, stop
again, the usual. A 1/3rd of a second is a long time for audio.

Agreed! 150ms delay in a conversation is far too much. It
completely breaks the flow. I hate digital phones. I can\'t
stand video conferencing. How can people possibly tolerate
this?

Jeroen Belleman

 

[Sjouke Burry]

On 30.07.20 23:39, Jeroen Belleman wrote:

On 2020-07-30 22:16, Joerg wrote:
On 2020-07-29 21:40, Joe Chisolm wrote:
[...]

ITU says 150ms one way, so called \"mouth to ear\". Cisco says that
can be pushed to a 200ms budget. Also > 30ms packet jitter can be
a problem. If you examine the video you normally see very little
movement with a conference. Some static power point slide while
people talk. Even video of people talking the back ground is very
static. Frame to frame compression can be very high, thus video
can be good but audio is poor.


Problem is, even with only 150msec it can take up to a 1/3rd of a
second (rount trip) to realize that the other guy must have started
talking at the same time. Then we both stop, both start again, stop
again, the usual. A 1/3rd of a second is a long time for audio.

Agreed! 150ms delay in a conversation is far too much. It
completely breaks the flow. I hate digital phones. I can\'t
stand video conferencing. How can people possibly tolerate
this?

Jeroen Belleman

They tolerate it, because they are unable to shrink the earth,
and/or built computers/networks which are 1000 times faster.

 

[Joerg]

On 2020-07-30 14:39, Jeroen Belleman wrote:

On 2020-07-30 22:16, Joerg wrote:
On 2020-07-29 21:40, Joe Chisolm wrote:
[...]

ITU says 150ms one way, so called \"mouth to ear\". Cisco says that
can be pushed to a 200ms budget. Also > 30ms packet jitter can be
a problem. If you examine the video you normally see very little
movement with a conference. Some static power point slide while
people talk. Even video of people talking the back ground is very
static. Frame to frame compression can be very high, thus video
can be good but audio is poor.


Problem is, even with only 150msec it can take up to a 1/3rd of a
second (rount trip) to realize that the other guy must have started
talking at the same time. Then we both stop, both start again, stop
again, the usual. A 1/3rd of a second is a long time for audio.

Agreed! 150ms delay in a conversation is far too much. It
completely breaks the flow.

It seems not everyone understands this.

... I hate digital phones. I can\'t
stand video conferencing. How can people possibly tolerate
this?

I am ok with video calls. VoIP was horrid for years, complete words
dropping out. Clients who switched to VoIP sometimes had to use their
personal cell phones so could discuss something. It has gotten better.

--
Regards, Joerg

http://www.analogconsultants.com/

 

[Joerg]

On 2020-07-30 14:05, Martin Brown wrote:

On 30/07/2020 21:29, Joerg wrote:
On 2020-07-30 05:38, Martin Brown wrote:
On 29/07/2020 19:29, Joerg wrote:

I notice that problem only when overseas parties are participating,
hardly ever with anyone is on the US West Coast.

I do see pings that are *much* slower to the US West coast than into the
East Coast or Chicago but the congestion is internal to the USA. You
just may be unlucky in your choice of European country or city but
German telecoms infrastructure should be OK.

For example, I just pinged my old health care provideer in Europe for
a test, 171-175msec. It is a very large company with good IT
infrastructure. Pinging Intel in California results in 12-17msec.

Try pinging somewhere physically on the US East coast and I expect you
will find >100ms delays to there too. Weirdly I just tried pinging
UCSD.edu and to my surprise got a 55ms ping response.

Large corporations and universities often have \"mirror\" servers in
more than one continent. The problem arises when they don\'t. It often
depends

Yes. Looks like they have something in London then.

on where in the world you are. For example, to Japan I get 110-120msec
and it\'s probably more for you in the UK. Try pinging
http://ikuta-sanki.com, for example.

290ms +/- 2ms so reproducible but quite a high delay but it is half way
round the world from here.

Ouch. That makes Internet calls quite unpleasant.

... We do on occasion
have bandwidth issues which are also local problems. I don\'t turn on
my video because of my Internet connection being poor in both latency
and bandwidth.

See? That\'s what I mean. IME the audio latency does not improve when
turning off the video. That we only do when the bandwidth on the other
side is too skimpy.

The audio quality sometimes goes haywire though with video on. Sort of
like a motorboat effect.

They should always, always prioritize audio over video. Video without
audio is typically useless. Audio without video allows the conference
to go on.

Indeed. Video freezes first when the thing stalls or is about to stall.

That\'s how it should be but even the engineers and the major providers
haven\'t understood that for years. Well, they should have served in the
Signal Corps

--
Regards, Joerg

http://www.analogconsultants.com/

 

[Lasse Langwadt Christensen]

fredag den 31. juli 2020 kl. 01.16.46 UTC+2 skrev Joerg:

On 2020-07-30 14:39, Jeroen Belleman wrote:
On 2020-07-30 22:16, Joerg wrote:
On 2020-07-29 21:40, Joe Chisolm wrote:
[...]

ITU says 150ms one way, so called \"mouth to ear\". Cisco says that
can be pushed to a 200ms budget. Also > 30ms packet jitter can be
a problem. If you examine the video you normally see very little
movement with a conference. Some static power point slide while
people talk. Even video of people talking the back ground is very
static. Frame to frame compression can be very high, thus video
can be good but audio is poor.


Problem is, even with only 150msec it can take up to a 1/3rd of a
second (rount trip) to realize that the other guy must have started
talking at the same time. Then we both stop, both start again, stop
again, the usual. A 1/3rd of a second is a long time for audio.

Agreed! 150ms delay in a conversation is far too much. It
completely breaks the flow.


It seems not everyone understands this.


... I hate digital phones. I can\'t
stand video conferencing. How can people possibly tolerate
this?


I am ok with video calls. VoIP was horrid for years, complete words
dropping out. Clients who switched to VoIP sometimes had to use their
personal cell phones so could discuss something. It has gotten better.

afair the round trip on GSM is allowed to be ~140ms, ~180ms with hands free
but it as long as it has good echo cancelling it seems to work alright

 

[server]

On Thu, 30 Jul 2020 13:54:35 -0700 (PDT), whit3rd <whit3rd@gmail.com>
wrote:

On Thursday, July 30, 2020 at 10:03:22 AM UTC-7, jla...@highlandsniptechnology.com wrote:
On Thu, 30 Jul 2020 08:40:32 -0700 (PDT), whit3rd <whit3rd@gmail.com
wrote:

There\'s international agreement on how the WHO reports are handled,
but local quirks make most data questionable for a variety of reasons (mainly
just innocent).

In recent weeks, SF has had very odd infection/death ratios, completely
unlikely and out of sync with the rest of the nation. Why?

SF\'s PPM death count is very low. Maybe it\'s the climate, cool with
very high humidity.

Oh, pull the other one! The climate for a virus is about 98,6 Fahrenheit and
one hundred percent humidity. This is about INFECTIONS that do happen,
and DEATHS that do not.

The count is very low, and there IS some kind of reason, but while a climate
might affect transmission rate, that\'s clearly not what causes low death
probability.

OK, suggest a reason.

Explain the curve in Australia too.



--

John Larkin Highland Technology, Inc

Science teaches us to doubt.

Claude Bernard

 

[Ricketty C]

On Thursday, July 30, 2020 at 2:01:20 AM UTC-4, Don Y wrote:

On 7/29/2020 10:31 PM, Ricketty C wrote:

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.

I\'m just tired of going round and round about this. As I\'ve said several times, the measurements give me nothing of value. You even acknowledge that above. The bandwidth I gave is a MAXIMUM, not a sustained rate at all times. I very clearly explained how it varies hugely depending on the usage of the system by the many other customers.

There is no reason for me to ask other people I conference with to dig to find useless data on their ends. There is real work to be done.

Thanks for your comments.

--

Rick C.

+-+ Get 1,000 miles of free Supercharging
+-+ Tesla referral code - https://ts.la/richard11209

 

[Ricketty C]

On Thursday, July 30, 2020 at 11:51:00 AM UTC-4, Martin Brown wrote:

On 30/07/2020 06:31, Ricketty C wrote:

Joe talked about 25 Mbps being ok. I have 7 Mbps max and often only see 2 or 3 Mbps.

It video gets pretty iffy when you get down to 2 or 3Mbps.

My connection is 6Mbps on a good dry summers day and degrades with rain
to about 3Mbps. Anything better than about 3.5M will support HD video
with the occassional buffering lag or sync loss in the video stream but
the audio pretty much continuously OK. On a really bad wet and windy day
it can\'t even stream high quality audio reliably.

All bets are off if there is a hard error on my local line which causes
a 1s glitch whilst lost packets are retransmitted and if they also fail
it enters exponential backoff. I get about 5 of those an hour even with
interleaving error correction enabled. My modem uptime before there is a
completely unrecoverable line error is 2-3 weeks. It gets stuck in a
state where it claims in sync but error seconds increase in realtime.

The odd one according to Murphy\'s Law lands where it can do most damage.

You might want to look at your line statistics attenuation and SNR to
see what proportion of hard and soft errors the modem is encountering.

What would I then do with that information?

--

Rick C.

++- Get 1,000 miles of free Supercharging
++- Tesla referral code - https://ts.la/richard11209

 

[Ricketty C]

On Thursday, July 30, 2020 at 4:16:36 PM UTC-4, Joerg wrote:

On 2020-07-29 21:40, Joe Chisolm wrote:
On Wed, 29 Jul 2020 11:29:19 -0700, Joerg wrote:

On 2020-07-29 11:08, Ricketty C wrote:

[...]

The goofy thing is the bandwidth issues show up first in the audio
rather than letting the video degrade. Without audio the whole thing
is pointless. We tried one of the other services because of the 40
minute meeting limitation on Zoom for free accounts and found the other
service was very blurry when the camera moved. Zoom was much more
clear. Maybe the other service was preserving bandwidth, lol.


That is one of my pet peeve. So far Zoom is one of the few services
where their engineers understand that audio is #1, always. Us guys in
the Signal Corps 40-some years ago already knew that back then.

ITU says 150ms one way, so called \"mouth to ear\". Cisco says that
can be pushed to a 200ms budget. Also > 30ms packet jitter can
be a problem. If you examine the video you normally see very
little movement with a conference. Some static power point slide
while people talk. Even video of people talking the back ground
is very static. Frame to frame compression can be very high, thus
video can be good but audio is poor.


Problem is, even with only 150msec it can take up to a 1/3rd of a second
(rount trip) to realize that the other guy must have started talking at
the same time. Then we both stop, both start again, stop again, the
usual. A 1/3rd of a second is a long time for audio.

If you are doing that with a third of a second round trip delay, you need to cut down on the caffeine. As I already said, a third of a second is the threshold commonly considered to be a perceptible delay for most purposes. It will not interfere in any significant way with normal conversation.

Yes, less caffeine is highly recommended.

--

Rick C.

---- Get 1,000 miles of free Supercharging
---- Tesla referral code - https://ts.la/richard11209

 

[whit3rd]

On Thursday, July 30, 2020 at 8:17:47 PM UTC-7, jla...@highlandsniptechnology.com wrote:

On Thu, 30 Jul 2020 13:54:35 -0700 (PDT), whit3rd <whit3rd@gmail.com
wrote:

On Thursday, July 30, 2020 at 10:03:22 AM UTC-7, jla...@highlandsniptechnology.com wrote:
On Thu, 30 Jul 2020 08:40:32 -0700 (PDT), whit3rd <whit3rd@gmail.com
wrote:

In recent weeks, SF has had very odd infection/death ratios, completely
unlikely and out of sync with the rest of the nation. Why?

SF\'s PPM death count is very low. Maybe it\'s the climate, cool with
very high humidity.

Oh, pull the other one! The climate for a virus is about 98,6 Fahrenheit and
one hundred percent humidity. This is about INFECTIONS that do happen,
and DEATHS that do not.

OK, suggest a reason.

Two possibilities: SF exports failing patients to outside facilities, or
SF doesn\'t get direct death reports, has to wait for a state agency to
divulge (SF doesn\'t license all the surrounding cemeteries, either).
Neither of those hypothesis fails to fit the data.

> Explain the curve in Australia too.

Oh, that\'s well known. The rocky bits displace the Pacific. You can verify this
by moving rocks, or watching for a tide cycle. Maybe your buddy Bill will shift
a stone for you? Timed satellite erial views are available, I\'m sure.

 

[Mikko OH2HVJ]

Joerg <news@analogconsultants.com> writes:

Problem is, even with only 150msec it can take up to a 1/3rd of a
second (rount trip) to realize that the other guy must have started
talking at the same time. Then we both stop, both start again, stop
again, the usual. A 1/3rd of a second is a long time for audio.

Different services also have had quite big differences in delays - in
April I noticed a LOT of this with some services while other services
caused no problems in discussion. Sometime we had to treat Teams as
half-duplex media with handshakes and arbitrator to get the meeting
done..


--
mikko

 

[Don Y]

On 7/30/2020 11:13 PM, Ricketty C wrote:

On Thursday, July 30, 2020 at 2:01:20 AM UTC-4, Don Y wrote:

I\'m just tired of going round and round about this. As I\'ve said several
times, the measurements give me nothing of value.

What do you think these tools were designed to do? Do YOU understand how an
internet works? The tools let you identify routing and delays for a particular
connection at a particular time.

Armed with this information, you can identify bottlenecks (in time and/or
bandwidth) along the route. (what would you do if you were a REAL COMPANY
and discovered that the bottleneck was the $49 router someone stuck in the
engineering department closet?)

With that, you can:
- opt to find another provider (on one end or the other, or both)
- opt NOT to use a particular \"service\" (regardless of where it is
hosted) due to the timeliness and bandwidth that it requires

When I travel to offsites, I configure one of my servers as an iSCSI target.
I can then mount EVERYTHING on my -- now remote -- laptop and act as if I
was working out of my office (thru an encrypted tunnel) -- without having
to drag a complete copy of EVERYTHING with me!

Because I\'ve used these tools (that you disdain as not providing YOU with
any useful information), I know that I can do many activities remotely
with minimal impact on my \"working efficiency\". Yeah, I may have to wait
100ms to access a particular block... but, it will likely be seconds or
more before I\'ll move on to want to access another block. BFD!

The flexibility of being able to access ANY block -- without having to
image my entire store and carry it with me -- is worth the delay and
reduced bandwidth (note that local caching on the initiator means I
don\'t have to re-request the block once I\'ve got it).

So, I can call up \'scope traces to show colleagues... datasheets for
the components I used... documentation that I\'ve prepared... source
code.... schematics... photos of prototypes... ANYTHING!

Furthermore, I could use any of the tools that I would have \"back home\"
FROM that laptop using that store -- not just \"access files\" in a piecemeal
fashion (like FTP).

OTOH, acknowledging the delay and bandwidth limitations, I\'d not be
inclined to \'make world\' from that laptop. *But*, I could conceivably
patch some code, recompile a module, and relink all while seated at
the laptop. Handy if I want to try out an idea that a colleague has
suggested OR want to illustrae why an idea won\'t achieve the desired
result.

[I can also run an X server on the laptop and let MY server do the
work -- remoting just the user interface. Again, at some inconvenience
based on the bandwidth and delays of the connection that I\'m using at the
time.]

Similarly, my colleagues can access their servers/datasets. If
the path to their server is \"better\" than mine, they may choose to
invoke more \"costly\" services than I would.

And, when the hosting party changes at the next offsite, the same
approach applies -- but with different paths (routes).

The tools let me/them quantify these parameters. As they would let you.
You\'ve just decided you can\'t (won\'t) change ISPs and can\'t (won\'t)
change conferencing services.

SnailMail might be a viable (safely tied to the past) option!

You even acknowledge that
above. The bandwidth I gave is a MAXIMUM, not a sustained rate at all
times. I very clearly explained how it varies hugely depending on the usage
of the system by the many other customers.

There is no reason for me to ask other people I conference with to dig to
find useless data on their ends. There is real work to be done.

Thanks for your comments.

 

[Martin Brown]

On 31/07/2020 07:20, Ricketty C wrote:

On Thursday, July 30, 2020 at 11:51:00 AM UTC-4, Martin Brown wrote:
On 30/07/2020 06:31, Ricketty C wrote:

Joe talked about 25 Mbps being ok. I have 7 Mbps max and often only see 2 or 3 Mbps.

It video gets pretty iffy when you get down to 2 or 3Mbps.

My connection is 6Mbps on a good dry summers day and degrades with rain
to about 3Mbps. Anything better than about 3.5M will support HD video
with the occassional buffering lag or sync loss in the video stream but
the audio pretty much continuously OK. On a really bad wet and windy day
it can\'t even stream high quality audio reliably.

All bets are off if there is a hard error on my local line which causes
a 1s glitch whilst lost packets are retransmitted and if they also fail
it enters exponential backoff. I get about 5 of those an hour even with
interleaving error correction enabled. My modem uptime before there is a
completely unrecoverable line error is 2-3 weeks. It gets stuck in a
state where it claims in sync but error seconds increase in realtime.

The odd one according to Murphy\'s Law lands where it can do most damage.

You might want to look at your line statistics attenuation and SNR to
see what proportion of hard and soft errors the modem is encountering.

What would I then do with that information?

You would at least know that you should be asking your ISP to check the
phone line for faults and remake any failing joints. It happens to me
every couple of years when either rodents chew through insulation, trees
wear it off or corrosion leads to rectification of the ADSL signal.

Of course you could choose to remain ignorant of your line quality and
suffer in silence or mutter on about it ineffectually here.

What you measure gets controlled.

--
Regards,
Martin Brown

 

[server]

On Fri, 31 Jul 2020 00:09:06 -0700 (PDT), whit3rd <whit3rd@gmail.com>
wrote:

On Thursday, July 30, 2020 at 8:17:47 PM UTC-7, jla...@highlandsniptechnology.com wrote:
On Thu, 30 Jul 2020 13:54:35 -0700 (PDT), whit3rd <whit3rd@gmail.com
wrote:

On Thursday, July 30, 2020 at 10:03:22 AM UTC-7, jla...@highlandsniptechnology.com wrote:
On Thu, 30 Jul 2020 08:40:32 -0700 (PDT), whit3rd <whit3rd@gmail.com
wrote:

In recent weeks, SF has had very odd infection/death ratios, completely
unlikely and out of sync with the rest of the nation. Why?

SF\'s PPM death count is very low. Maybe it\'s the climate, cool with
very high humidity.

Oh, pull the other one! The climate for a virus is about 98,6 Fahrenheit and
one hundred percent humidity. This is about INFECTIONS that do happen,
and DEATHS that do not.

OK, suggest a reason.

Two possibilities: SF exports failing patients to outside facilities, or
SF doesn\'t get direct death reports, has to wait for a state agency to
divulge (SF doesn\'t license all the surrounding cemeteries, either).
Neither of those hypothesis fails to fit the data.

Explain the curve in Australia too.

Oh, that\'s well known. The rocky bits displace the Pacific. You can verify this
by moving rocks, or watching for a tide cycle. Maybe your buddy Bill will shift
a stone for you? Timed satellite erial views are available, I\'m sure.

You have an aggressive refusal to think. That\'s bad in general and
especially bad for designing electronics.

It\'s not unusual, either.



--

John Larkin Highland Technology, Inc

Science teaches us to doubt.

Claude Bernard

 

[Joerg]

On 2020-07-30 16:24, Lasse Langwadt Christensen wrote:

fredag den 31. juli 2020 kl. 01.16.46 UTC+2 skrev Joerg:
On 2020-07-30 14:39, Jeroen Belleman wrote:

[...]

... I hate digital phones. I can\'t
stand video conferencing. How can people possibly tolerate
this?


I am ok with video calls. VoIP was horrid for years, complete words
dropping out. Clients who switched to VoIP sometimes had to use their
personal cell phones so could discuss something. It has gotten better.

afair the round trip on GSM is allowed to be ~140ms, ~180ms with hands free
but it as long as it has good echo cancelling it seems to work alright

I had to switch to GSM last year when my previous cell carrier
discontinued and that effect was noticeable. On the prior CDMA network
talking over each other happened less.

--
Regards, Joerg

http://www.analogconsultants.com/

 

[Jeroen Belleman]

On 2020-07-30 23:50, Sjouke Burry wrote:

On 30.07.20 23:39, Jeroen Belleman wrote:
On 2020-07-30 22:16, Joerg wrote:
On 2020-07-29 21:40, Joe Chisolm wrote:
[...]

ITU says 150ms one way, so called \"mouth to ear\". Cisco says that
can be pushed to a 200ms budget. Also > 30ms packet jitter can be
a problem. If you examine the video you normally see very little
movement with a conference. Some static power point slide while
people talk. Even video of people talking the back ground is very
static. Frame to frame compression can be very high, thus video
can be good but audio is poor.


Problem is, even with only 150msec it can take up to a 1/3rd of a
second (rount trip) to realize that the other guy must have started
talking at the same time. Then we both stop, both start again, stop
again, the usual. A 1/3rd of a second is a long time for audio.

Agreed! 150ms delay in a conversation is far too much. It
completely breaks the flow. I hate digital phones. I can\'t
stand video conferencing. How can people possibly tolerate
this?

Jeroen Belleman

They tolerate it, because they are unable to shrink the earth,
and/or built computers/networks which are 1000 times faster.

You have evidently never used an old analog phone. No perceptible
latency, no drop-outs, no weird distortions. But that era is well
behind us.

Jeroen Belleman

 

[Joerg]

On 2020-07-31 00:30, Mikko OH2HVJ wrote:

Joerg <news@analogconsultants.com> writes:

Problem is, even with only 150msec it can take up to a 1/3rd of a
second (rount trip) to realize that the other guy must have started
talking at the same time. Then we both stop, both start again, stop
again, the usual. A 1/3rd of a second is a long time for audio.

Different services also have had quite big differences in delays - in
April I noticed a LOT of this with some services while other services
caused no problems in discussion. Sometime we had to treat Teams as
half-duplex media with handshakes and arbitrator to get the meeting
done..

It might depend on how busy their servers are. I had a recent Teams
meeting that was nearly latency-free. However, that was only to San
Diego which is about 500mi or 800km from here. Not sure which server
then gets used.

Now, if everyone had a ham radio license and the proper equipment ...

--
Regards, Joerg

http://www.analogconsultants.com/

 

[John Larkin]

On Fri, 31 Jul 2020 22:12:08 +0200, Jeroen Belleman
<jeroen@nospam.please> wrote:

On 2020-07-30 23:50, Sjouke Burry wrote:
On 30.07.20 23:39, Jeroen Belleman wrote:
On 2020-07-30 22:16, Joerg wrote:
On 2020-07-29 21:40, Joe Chisolm wrote:
[...]

ITU says 150ms one way, so called \"mouth to ear\". Cisco says that
can be pushed to a 200ms budget. Also > 30ms packet jitter can be
a problem. If you examine the video you normally see very little
movement with a conference. Some static power point slide while
people talk. Even video of people talking the back ground is very
static. Frame to frame compression can be very high, thus video
can be good but audio is poor.


Problem is, even with only 150msec it can take up to a 1/3rd of a
second (rount trip) to realize that the other guy must have started
talking at the same time. Then we both stop, both start again, stop
again, the usual. A 1/3rd of a second is a long time for audio.

Agreed! 150ms delay in a conversation is far too much. It
completely breaks the flow. I hate digital phones. I can\'t
stand video conferencing. How can people possibly tolerate
this?

Jeroen Belleman

They tolerate it, because they are unable to shrink the earth,
and/or built computers/networks which are 1000 times faster.

You have evidently never used an old analog phone. No perceptible
latency, no drop-outs, no weird distortions. But that era is well
behind us.

Jeroen Belleman

Latency? You had to call the operator to set up a long-distance call.
She\'d call back when they were ready.

The quality could be really bad.