[Lex Computer & Tech Group/LCTG] LCTG Digest, Vol 6, Issue 16

Steve Isenberg smisenberg at gmail.com
Sun Mar 22 12:04:56 PDT 2020


Stephen,
I believe that FiOS provides you a fiber connection back to the Verizon
office so that any use of Internet services by your neighbors would have no
effect on your use.  (Correct me if I'm wrong!). The problem could be
caused by congestion back at the Verizon office; hasn't been affecting my
use of Zoom (i.e., my students don't complain, or at least complain about
that :)

This Wednesday please let me know using the Chat window during the meeting
or via email after the meeting if you are having any latency issues.
Thanks,
-steve

On Sun, Mar 22, 2020 at 12:30 PM Stephen Quatrano <stefanoq at gmail.com>
wrote:

> I’m seeing problems now too with Zoom and Verizon FIOS:  a lot more
> latency than usual.  I suspect this is “edge” congestion in my neighborhood
> that only the carrier can resolve, not a problem with the backbone.  Or it
> is a problem with Zoom bandwidth or their data center which only they can
> resolve.  Either way, not much I can do.
>
> When you say ‘streaming dropouts’ I presume you are talking about video
> streaming services like Netflix.  One way to see if the problem is there is
> to try another service.  I’m having fun with Kanopy
> https://carylibrary.kanopy.com/frontpage which has 10’s of thousands of
> documentaries and indie movies from the LIBRARY.   All you need is a
> library card!!
>
> So cool.
>
> SQ
>
> On Mar 22, 2020, at 12:11 PM, Kenneth Cutter <ken at kencutter.com> wrote:
>
> The bottom line for me is that I experience several streaming dropouts per
> day- Even before the currrent crisis. Some dropouts result in a hard crash
> where it takes 5 minutes to recover.
> I have run the Xfinity speed test and it always shows more than 200 MPs.
> But even if it did show a problem, what can I do? The router is a new unit
> from Comcast.
> Any suggestions?
>
> On Sat, Mar 21, 2020 at 4:36 PM <lctg-request at lists.toku.us> wrote:
>
>> Send LCTG mailing list submissions to
>>         lctg at lists.toku.us
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         http://lists.toku.us/listinfo.cgi/lctg-toku.us
>> or, via email, send a message with subject or body 'help' to
>>         lctg-request at lists.toku.us
>>
>> You can reach the person managing the list at
>>         lctg-owner at lists.toku.us
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of LCTG digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Re: Internet is hefty (mwolfe at vinebrook.com)
>>    2. Re: Internet is hefty (Robert Primak)
>>    3. Re: Internet is hefty (stefanoq at gmail.com)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Fri, 20 Mar 2020 17:10:56 -0400
>> From: mwolfe at vinebrook.com
>> To: Stephen Quatrano <stefanoq at gmail.com>
>> Cc: Carl Lazarus <carllazarus at comcast.net>, Lex Computer Group
>>         <LCTG at lists.toku.us>
>> Subject: Re: [Lex Computer & Tech Group/LCTG] Internet is hefty
>> Message-ID: <1145c9c881612edd9fe2a52395b0e8e2 at vinebrook.com>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> To All:
>>
>> WIRED just posted a similar article:
>> https://www.wired.com/story/stream-all-want-internet-fine-now
>>
>> _"Go Ahead, Stream All You Want. The Internet Is Fine--for Now"_
>>
>> ISPs normally need to plan for about a 50% annual increase in network
>> traffic anyway. Some highly affected coronvirus areas since January
>> already may have experienced higher peaks of this magnitude.
>>
>> In addition to video compression (encoding algorithms, reducing
>> fidelity, etc.), there is a lot of aggressive content caching for
>> delivering static video. For example, Netflix used to consume 30% of US
>> total network capacity nightly during consumer prime time (8PM-11PM).
>> Netflix provides free caching appliances for bigger ISPs to localize
>> content delivery and to reduce more global loading:
>> https://openconnect.netflix.com/en/
>>
>> Voice grade connections typically sample at 8 kHz using 8-bit pulse code
>> modulation for a raw rate of 64 kbit/sec before compression. This is a
>> lot less than video.
>>
>> Both video and voice are somewhat dependent upon real-time delivery
>> because delays degrade intelligibility. Buffering helps maintain
>> continuity for video streams assuming that the average available
>> sustained bandwidth is sufficient.
>>
>> -- Mitch
>>
>> On 2020-03-20 11:34, Stephen Quatrano wrote:
>>
>> > "Amazon is cutting Prime Video streaming bitrates in Europe"
>> > "Netflix and YouTube have made similar decisions in the last 24 hours."
>> >
>> >
>> https://www.engadget.com/2020/03/20/amazon-prime-video-streaming-bitrate-europe/?utm_medium=techboard.fri.20200320&utm_source=email&utm_content=&utm_campaign=campaign
>> >
>> > One of my friend in the business claimed that Netflix has actually
>> asked NBC to stop broadcasting in HD.  I have not looked into that so I
>> cannot confirm it.
>> >
>> > These are examples of feedback that will dynamically alleviate
>> congestion.  Very interesting.
>> >
>> > SQ
>> >
>> > On Mar 19, 2020, at 2:44 PM, Stephen Quatrano <stefanoq at gmail.com>
>> wrote:
>> >
>> > Very good point!  The best services figure out ways of failing
>> gracefully.  For example, loosing a couple of frames of video are just not
>> as serious as loosing voice.
>> >
>> > Unlike movies, though, conference endpoints cannot buffer as much to
>> accommodate congestion in the datacenter or at the edge because of
>> latency.  We are very used to low latency phone calls... and users unable
>> to interrupt are often unhappy with buffered solutions.  We often chose to
>> drop packets, sometimes a LOT of them, to preserve the call session and
>> avoid buffering.
>> >
>> > SQ
>> >
>> > On Mar 19, 2020, at 12:39 PM, Carl Lazarus <carllazarus at comcast.net>
>> wrote:
>> >
>> > Video conferencing might not be such a bandwidth hog.  The algorithms
>> it uses send changes rather than constantly sending the whole picture.
>> Unlike a movie, the participants in a video conference are not moving
>> around much.
>> > -- Carl
>> >
>> > FROM: LCTG [mailto:lctg-bounces+carllazarus=comcast.net at lists.toku.us]
>> ON BEHALF OF Stephen Quatrano
>> > SENT: Thursday, March 19, 2020 12:02 PM
>> > TO: <jjrudy1 at comcast.net> <jjrudy1 at comcast.net>
>> > CC: Lex Computer Group <LCTG at lists.toku.us>; lexington at groups.io
>> > SUBJECT: Re: [Lex Computer & Tech Group/LCTG] Internet is hefty
>> >
>> > It'll be a problem if "working from home" means "watching Netflix".  It
>> might also be a problem if "working from home" means "endless meetings" and
>> "always-on video conferencing."  On the other hand, if people are actually
>> doing work, well, not so much.
>> >
>> > You get my point.  It's about bandwidth.  I believe that about 80% of
>> all Internet traffic is already video.   Texting, email, web, and even FB
>> is essentially noise with respect to these volumes...
>> >
>> > SQ
>> >
>> > On Mar 19, 2020, at 11:52 AM, <jjrudy1 at comcast.net> <
>> jjrudy1 at comcast.net> wrote:
>> >
>> > A number of folks have asked whether the internet can handle the surge
>> in volume seen during the last week or two.  Consensus appears to be
>> maybe/probably.  Here are a few recent articles
>> >
>> >
>> https://www.datacenterknowledge.com/uptime/will-coronavirus-break-internet-highly-unlikely-says-cloudflare
>> [1]
>> >
>> >
>> https://www.nytimes.com/2020/03/17/opinion/coronavirus-broadband-internet-work-from-home.html?auth=login-facebook
>> [2]
>> >
>> >
>> https://www.buzzfeednews.com/article/alexkantrowitz/the-internet-was-built-to-withstand-a-nuclear-bomb-it-will
>> [3]
>> >
>> >
>> https://www.cnn.com/2020/03/17/tech/internet-infrastructure-coronavirus/index.html
>> [4]
>> >
>> > The bottom line in my view is that the experts are not sure, but think
>> it can.   And of course this is somewhat geography-dependent
>> >
>> > On Monday I tried to get onto the Met Opera to watch Carmen and could
>> not.  THEIR server was apparently flooded.  Later on it was fine.
>> >
>> > John
>> >
>> > John Rudy
>> >
>> > 781-861-0402
>> >
>> > 781-718-8334 (cell)
>> >
>> > 20 Heritage Drive
>> >
>> > Lexington, MA  02420
>> >
>> > ===============================================
>> > ::The Lexington Computer and Technology Group Mailing List::
>> > Reply goes to sender only; Reply All to send to list.
>> > Send to the list: LCTG at lists.toku.us      Message archives:
>> http://lists.toku.us/private.cgi/lctg-toku.us [5]
>> > To subscribe: email lctg-subscribe at toku.us  To unsubscribe: email
>> lctg-unsubscribe at toku.us
>> > Future and Past meeting information: http://LCTG.toku.us
>> <http://lctg.toku.us/> [6]
>> > This message was sent to stefanoq at gmail.com.
>> > Set your list options:
>> http://lists.toku.us/options.cgi/lctg-toku.us/stefanoq@gmail.com [7]
>>
>> ===============================================
>> ::The Lexington Computer and Technology Group Mailing List::
>> Reply goes to sender only; Reply All to send to list.
>> Send to the list: LCTG at lists.toku.us      Message archives:
>> http://lists.toku.us/private.cgi/lctg-toku.us
>> To subscribe: email lctg-subscribe at toku.us  To unsubscribe: email
>> lctg-unsubscribe at toku.us
>> Future and Past meeting information: http://LCTG.toku.us
>> <http://lctg.toku.us/>
>> This message was sent to mwolfe at vinebrook.com.
>> Set your list options:
>> http://lists.toku.us/options.cgi/lctg-toku.us/mwolfe@vinebrook.com
>>
>>
>>
>> Links:
>> ------
>> [1]
>>
>> https://www.datacenterknowledge.com/uptime/will-coronavirus-break-internet-highly-unlikely-says-cloudflare
>> [2]
>>
>> https://www.nytimes.com/2020/03/17/opinion/coronavirus-broadband-internet-work-from-home.html?auth=login-facebook
>> [3]
>>
>> https://www.buzzfeednews.com/article/alexkantrowitz/the-internet-was-built-to-withstand-a-nuclear-bomb-it-will
>> [4]
>>
>> https://www.cnn.com/2020/03/17/tech/internet-infrastructure-coronavirus/index.html
>> [5] http://lists.toku.us/private.cgi/lctg-toku.us
>> [6] http://lctg.toku.us/
>> [7] http://lists.toku.us/options.cgi/lctg-toku.us/stefanoq@gmail.com
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.toku.us/private.cgi/lctg-toku.us/attachments/20200320/6e9170d0/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Sat, 21 Mar 2020 00:27:50 +0000 (UTC)
>> From: Robert Primak <bobprimak at yahoo.com>
>> To: Stephen Quatrano <stefanoq at gmail.com>,  <mwolfe at vinebrook.com>
>> Cc: Lex Computer Group <lctg at lists.toku.us>
>> Subject: Re: [Lex Computer & Tech Group/LCTG] Internet is hefty
>> Message-ID: <116430597.1905937.1584750470277 at mail.yahoo.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>>  "Netflix has actually asked NBC to stop broadcasting in HD"
>> I think you mean?Netflix has actually asked NBC to stop streaming in HD.
>> Current format ATSC-1 OTA TV broadcasts have nothing to do with the
>> Internet.
>> -- Bob Primak
>>
>>     On Friday, March 20, 2020, 05:11:04 PM EDT, <mwolfe at vinebrook.com>
>> wrote:
>>
>>
>> To All:
>>
>> WIRED just posted a similar article:
>> https://www.wired.com/story/stream-all-want-internet-fine-now
>>
>> "Go Ahead, Stream All You Want. The Internet Is Fine?for Now"
>>
>> ISPs normally need to plan for about a 50% annual increase in network
>> traffic anyway. Some highly affected coronvirus areas since January already
>> may have experienced higher peaks of this magnitude.
>>
>> In addition to video compression (encoding algorithms, reducing fidelity,
>> etc.), there is a lot of aggressive content caching for delivering static
>> video. For example, Netflix used to consume 30% of US total network
>> capacity nightly during consumer prime time (8PM-11PM). Netflix provides
>> free caching appliances for bigger ISPs to localize content delivery and to
>> reduce more global loading:
>> https://openconnect.netflix.com/en/
>>
>> Voice grade connections typically sample at 8 kHz using 8-bit pulse code
>> modulation for a raw rate of 64 kbit/sec before compression. This is a lot
>> less than video.
>>
>> Both video and voice are somewhat dependent upon real-time delivery
>> because delays degrade intelligibility. Buffering helps maintain continuity
>> for video streams assuming that the average available sustained bandwidth
>> is sufficient.
>>
>> -- Mitch
>>
>> On 2020-03-20 11:34, Stephen Quatrano wrote:
>>
>> "Amazon is cutting Prime Video streaming?bitrates in Europe"
>> "Netflix and YouTube have made similar decisions in the last 24 hours."
>>
>>
>> https://www.engadget.com/2020/03/20/amazon-prime-video-streaming-bitrate-europe/?utm_medium=techboard.fri.20200320&utm_source=email&utm_content=&utm_campaign=campaign?One
>> of my friend in the business claimed that Netflix has actually asked NBC to
>> stop broadcasting in HD. ?I have not looked into that so I cannot confirm
>> it.?These are examples of feedback that will dynamically alleviate
>> congestion. ?Very interesting.?SQ
>>
>>
>> On Mar 19, 2020, at 2:44 PM, Stephen Quatrano <stefanoq at gmail.com>
>> wrote:Very good point! ?The best services figure out ways of failing
>> gracefully. ?For example, loosing a couple of frames of video are just not
>> as serious as loosing voice. ??Unlike movies, though, conference endpoints
>> cannot buffer as much to accommodate congestion in the datacenter or at the
>> edge because of latency. ?We are very used to low latency phone calls...
>> and users unable to interrupt are often unhappy with buffered solutions.
>> ?We often chose to drop packets, sometimes a LOT of them, to preserve the
>> call session and avoid buffering.?SQ
>>
>>
>> On Mar 19, 2020, at 12:39 PM, Carl Lazarus <carllazarus at comcast.net>
>> wrote:Video conferencing might not be such a bandwidth hog. ?The algorithms
>> it uses send changes rather than constantly sending the whole picture.?
>> Unlike a movie, the participants in a video conference are not moving
>> around much.-- Carl?From:?LCTG [mailto:lctg-bounces+carllazarus=
>> comcast.net at lists.toku.us]?On Behalf Of?Stephen Quatrano
>> Sent:?Thursday, March 19, 2020 12:02 PM
>> To:?<jjrudy1 at comcast.net> <jjrudy1 at comcast.net>
>> Cc:?Lex Computer Group <LCTG at lists.toku.us>;?lexington at groups.io
>> Subject:?Re: [Lex Computer & Tech Group/LCTG] Internet is hefty?It'll be
>> a problem if "working from home" means "watching Netflix". ?It might also
>> be a problem if "working from home" means "endless meetings" and "always-on
>> video conferencing." ?On the other hand, if people are actually doing work,
>> well, not so much.?You get my point. ?It's about bandwidth. ?I believe that
>> about 80% of all Internet traffic is already video. ? Texting, email, web,
>> and even FB is essentially noise with respect to these volumes...?SQ
>>
>>
>> On Mar 19, 2020, at 11:52 AM, <jjrudy1 at comcast.net> <jjrudy1 at comcast.net>
>> wrote:?A number of folks have asked whether the internet can handle the
>> surge in volume seen during the last week or two.? Consensus appears to be
>> maybe/probably.? Here are a few recent articles?
>> https://www.datacenterknowledge.com/uptime/will-coronavirus-break-internet-highly-unlikely-says-cloudflare?https://www.nytimes.com/2020/03/17/opinion/coronavirus-broadband-internet-work-from-home.html?auth=login-facebook?https://www.buzzfeednews.com/article/alexkantrowitz/the-internet-was-built-to-withstand-a-nuclear-bomb-it-will?https://www.cnn.com/2020/03/17/tech/internet-infrastructure-coronavirus/index.html?The
>> bottom line in my view is that the experts are not sure, but think it
>> can.?? And of course this is somewhat geography-dependent?On Monday I tried
>> to get onto the Met Opera to watch Carmen and could not.? THEIR server was
>> apparently flooded.? Later on it was fine.?John???John
>> Rudy781-861-0402781-718-8334 (cell
>>  )?20 Heritage DriveLexington, MA?
>> 02420?===============================================
>> ::The Lexington Computer and Technology Group Mailing List::
>> Reply goes to sender only; Reply All to send to list.
>> Send to the list:?LCTG at lists.toku.us??????Message
>> <http://LCTG@lists.toku.us/??????Message> archives:?
>> http://lists.toku.us/private.cgi/lctg-toku.us
>> To subscribe: email?lctg-subscribe at toku.us??To
>> <http://lctg-subscribe@toku.us/??To> unsubscribe: email?
>> lctg-unsubscribe at toku.us
>> Future and Past meeting information:?http://LCTG.toku.us
>> <http://lctg.toku.us/>
>> This message was sent to?stefanoq at gmail.com.
>> Set your list options:?
>> http://lists.toku.us/options.cgi/lctg-toku.us/stefanoq@gmail.com
>>
>>
>>
>> ===============================================
>>  ::The Lexington Computer and Technology Group Mailing List::
>>  Reply goes to sender only; Reply All to send to list.
>>  Send to the list: LCTG at lists.toku.us ?????Message archives:
>> http://lists.toku.us/private.cgi/lctg-toku.us
>>  To subscribe: email lctg-subscribe at toku.us ?To unsubscribe: email
>> lctg-unsubscribe at toku.us
>>  Future and Past meeting information: http://LCTG.toku.us
>> <http://lctg.toku.us/>
>>  This message was sent to mwolfe at vinebrook.com.
>>  Set your list options:
>> http://lists.toku.us/options.cgi/lctg-toku.us/mwolfe@vinebrook.com
>>
>>
>>
>> ===============================================
>> ::The Lexington Computer and Technology Group Mailing List::
>> Reply goes to sender only; Reply All to send to list.
>> Send to the list: LCTG at lists.toku.us? ? ? Message archives:
>> http://lists.toku.us/private.cgi/lctg-toku.us
>> To subscribe: email lctg-subscribe at toku.us? To unsubscribe: email
>> lctg-unsubscribe at toku.us
>> Future and Past meeting information: http://LCTG.toku.us
>> <http://lctg.toku.us/>
>> This message was sent to bobprimak at yahoo.com.
>> Set your list options:
>> http://lists.toku.us/options.cgi/lctg-toku.us/bobprimak@yahoo.com
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.toku.us/private.cgi/lctg-toku.us/attachments/20200321/4f5e4066/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Fri, 20 Mar 2020 23:50:39 -0400
>> From: stefanoq at gmail.com
>> To: Robert Primak <bobprimak at yahoo.com>
>> Cc: mwolfe at vinebrook.com, Lex Computer Group <lctg at lists.toku.us>
>> Subject: Re: [Lex Computer & Tech Group/LCTG] Internet is hefty
>> Message-ID: <B1F610EE-4051-474D-AF3C-52CDFFC44572 at gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Yep.
>>
>> Steve Q
>>
>> Sent from my mobile:  please excuse brevity, abbreviations, and typos.
>> (I'm NOT driving).
>>
>> > On Mar 20, 2020, at 8:27 PM, Robert Primak <bobprimak at yahoo.com> wrote:
>> >
>> > ?
>> > "Netflix has actually asked NBC to stop broadcasting in HD"
>> >
>> > I think you mean Netflix has actually asked NBC to stop streaming in HD.
>> >
>> > Current format ATSC-1 OTA TV broadcasts have nothing to do with the
>> Internet.
>> >
>> > -- Bob Primak
>> >
>> >
>> > On Friday, March 20, 2020, 05:11:04 PM EDT, <mwolfe at vinebrook.com>
>> wrote:
>> >
>> >
>> > To All:
>> >
>> > WIRED just posted a similar article:
>> > https://www.wired.com/story/stream-all-want-internet-fine-now
>> >
>> > "Go Ahead, Stream All You Want. The Internet Is Fine?for Now"
>> >
>> > ISPs normally need to plan for about a 50% annual increase in network
>> traffic anyway. Some highly affected coronvirus areas since January already
>> may have experienced higher peaks of this magnitude.
>> >
>> > In addition to video compression (encoding algorithms, reducing
>> fidelity, etc.), there is a lot of aggressive content caching for
>> delivering static video. For example, Netflix used to consume 30% of US
>> total network capacity nightly during consumer prime time (8PM-11PM).
>> Netflix provides free caching appliances for bigger ISPs to localize
>> content delivery and to reduce more global loading:
>> > https://openconnect.netflix.com/en/
>> >
>> > Voice grade connections typically sample at 8 kHz using 8-bit pulse
>> code modulation for a raw rate of 64 kbit/sec before compression. This is a
>> lot less than video.
>> >
>> > Both video and voice are somewhat dependent upon real-time delivery
>> because delays degrade intelligibility. Buffering helps maintain continuity
>> for video streams assuming that the average available sustained bandwidth
>> is sufficient.
>> >
>> > -- Mitch
>> >
>> >> On 2020-03-20 11:34, Stephen Quatrano wrote:
>> >>
>> >> "Amazon is cutting Prime Video streaming bitrates in Europe"
>> >> "Netflix and YouTube have made similar decisions in the last 24 hours."
>> >>
>> >>
>> https://www.engadget.com/2020/03/20/amazon-prime-video-streaming-bitrate-europe/?utm_medium=techboard.fri.20200320&utm_source=email&utm_content=&utm_campaign=campaign
>> >>
>> >> One of my friend in the business claimed that Netflix has actually
>> asked NBC to stop broadcasting in HD.  I have not looked into that so I
>> cannot confirm it.
>> >>
>> >> These are examples of feedback that will dynamically alleviate
>> congestion.  Very interesting.
>> >>
>> >> SQ
>> >>
>> >>
>> >>> On Mar 19, 2020, at 2:44 PM, Stephen Quatrano <stefanoq at gmail.com>
>> wrote:
>> >>> Very good point!  The best services figure out ways of failing
>> gracefully.  For example, loosing a couple of frames of video are just not
>> as serious as loosing voice.
>> >>>
>> >>> Unlike movies, though, conference endpoints cannot buffer as much to
>> accommodate congestion in the datacenter or at the edge because of
>> latency.  We are very used to low latency phone calls... and users unable
>> to interrupt are often unhappy with buffered solutions.  We often chose to
>> drop packets, sometimes a LOT of them, to preserve the call session and
>> avoid buffering.
>> >>>
>> >>> SQ
>> >>>
>> >>>> On Mar 19, 2020, at 12:39 PM, Carl Lazarus <carllazarus at comcast.net>
>> wrote:
>> >>>> Video conferencing might not be such a bandwidth hog.  The
>> algorithms it uses send changes rather than constantly sending the whole
>> picture.  Unlike a movie, the participants in a video conference are not
>> moving around much.
>> >>>> -- Carl
>> >>>>
>> >>>> From: LCTG [mailto:lctg-bounces+carllazarus=
>> comcast.net at lists.toku.us] On Behalf Of Stephen Quatrano
>> >>>> Sent: Thursday, March 19, 2020 12:02 PM
>> >>>> To: <jjrudy1 at comcast.net> <jjrudy1 at comcast.net>
>> >>>> Cc: Lex Computer Group <LCTG at lists.toku.us>; lexington at groups.io
>> >>>> Subject: Re: [Lex Computer & Tech Group/LCTG] Internet is hefty
>> >>>>
>> >>>> It'll be a problem if "working from home" means "watching Netflix".
>> It might also be a problem if "working from home" means "endless meetings"
>> and "always-on video conferencing."  On the other hand, if people are
>> actually doing work, well, not so much.
>> >>>>
>> >>>> You get my point.  It's about bandwidth.  I believe that about 80%
>> of all Internet traffic is already video.   Texting, email, web, and even
>> FB is essentially noise with respect to these volumes...
>> >>>>
>> >>>> SQ
>> >>>>
>> >>>>
>> >>>> On Mar 19, 2020, at 11:52 AM, <jjrudy1 at comcast.net> <
>> jjrudy1 at comcast.net> wrote:
>> >>>>
>> >>>> A number of folks have asked whether the internet can handle the
>> surge in volume seen during the last week or two.  Consensus appears to be
>> maybe/probably.  Here are a few recent articles
>> >>>>
>> >>>>
>> https://www.datacenterknowledge.com/uptime/will-coronavirus-break-internet-highly-unlikely-says-cloudflare
>> >>>>
>> >>>>
>> https://www.nytimes.com/2020/03/17/opinion/coronavirus-broadband-internet-work-from-home.html?auth=login-facebook
>> >>>>
>> >>>>
>> https://www.buzzfeednews.com/article/alexkantrowitz/the-internet-was-built-to-withstand-a-nuclear-bomb-it-will
>> >>>>
>> >>>>
>> https://www.cnn.com/2020/03/17/tech/internet-infrastructure-coronavirus/index.html
>> >>>>
>> >>>> The bottom line in my view is that the experts are not sure, but
>> think it can.   And of course this is somewhat geography-dependent
>> >>>>
>> >>>> On Monday I tried to get onto the Met Opera to watch Carmen and
>> could not.  THEIR server was apparently flooded.  Later on it was fine.
>> >>>>
>> >>>> John
>> >>>>
>> >>>>
>> >>>>
>> >>>> John Rudy
>> >>>> 781-861-0402
>> >>>> 781-718-8334 (cell)
>> >>>>
>> >>>> 20 Heritage Drive
>> >>>> Lexington, MA  02420
>> >>>>
>> >>>> ===============================================
>> >>>> ::The Lexington Computer and Technology Group Mailing List::
>> >>>> Reply goes to sender only; Reply All to send to list.
>> >>>> Send to the list: LCTG at lists.toku.us      Message archives:
>> http://lists.toku.us/private.cgi/lctg-toku.us
>> >>>> To subscribe: email lctg-subscribe at toku.us  To unsubscribe: email
>> lctg-unsubscribe at toku.us
>> >>>> Future and Past meeting information: http://LCTG.toku.us
>> <http://lctg.toku.us/>
>> >>>> This message was sent to stefanoq at gmail.com.
>> >>>> Set your list options:
>> http://lists.toku.us/options.cgi/lctg-toku.us/stefanoq@gmail.com
>> >>
>> >> ===============================================
>> >> ::The Lexington Computer and Technology Group Mailing List::
>> >> Reply goes to sender only; Reply All to send to list.
>> >> Send to the list: LCTG at lists.toku.us      Message archives:
>> http://lists.toku.us/private.cgi/lctg-toku.us
>> >> To subscribe: email lctg-subscribe at toku.us  To unsubscribe: email
>> lctg-unsubscribe at toku.us
>> >> Future and Past meeting information: http://LCTG.toku.us
>> <http://lctg.toku.us/>
>> >> This message was sent to mwolfe at vinebrook.com.
>> >>
>> >> Set your list options:
>> >> http://lists.toku.us/options.cgi/lctg-toku.us/mwolfe@vinebrook.com
>> >
>> > ===============================================
>> > ::The Lexington Computer and Technology Group Mailing List::
>> > Reply goes to sender only; Reply All to send to list.
>> > Send to the list: LCTG at lists.toku.us      Message archives:
>> http://lists.toku.us/private.cgi/lctg-toku.us
>> > To subscribe: email lctg-subscribe at toku.us  To unsubscribe: email
>> lctg-unsubscribe at toku.us
>> > Future and Past meeting information: http://LCTG.toku.us
>> <http://lctg.toku.us/>
>> > This message was sent to bobprimak at yahoo.com.
>> > Set your list options:
>> http://lists.toku.us/options.cgi/lctg-toku.us/bobprimak@yahoo.com
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.toku.us/private.cgi/lctg-toku.us/attachments/20200320/324fe349/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> ===============================================
>> ::Lexington Computer and Technology Group Mailing List digest::
>> Send to the list: LCTG at lists.toku.us    Message archives:
>> http://lists.toku.us/private.cgi/lctg-toku.us
>> To subscribe: email lctg-subscribe at toku.us     To unsubscribe: email
>> lctg-unsubscribe at toku.us
>> Future and Past meeting information: http://LCTG.toku.us
>> <http://lctg.toku.us/>
>> Visit http://lists.toku.us/options.cgi/lctg-toku.us/<Your email address>
>> to set your list options.
>>
>> ------------------------------
>>
>> End of LCTG Digest, Vol 6, Issue 16
>> ***********************************
>>
> ===============================================
> ::The Lexington Computer and Technology Group Mailing List::
> Reply goes to sender only; Reply All to send to list.
> Send to the list: LCTG at lists.toku.us      Message archives:
> http://lists.toku.us/private.cgi/lctg-toku.us
> To subscribe: email lctg-subscribe at toku.us <lctg-subscribe at toku.us>  To
> unsubscribe: email lctg-unsubscribe at toku.us <lctg-unsubscribe at toku.us>
> Future and Past meeting information: http://LCTG.toku.us
> This message was sent to stefanoq at gmail.com.
> Set your list options:
> http://lists.toku.us/options.cgi/lctg-toku.us/stefanoq@gmail.com
>
>
> ===============================================
> ::The Lexington Computer and Technology Group Mailing List::
> Reply goes to sender only; Reply All to send to list.
> Send to the list: LCTG at lists.toku.us      Message archives:
> http://lists.toku.us/private.cgi/lctg-toku.us
> To subscribe: email lctg-subscribe at toku.us  To unsubscribe: email
> lctg-unsubscribe at toku.us
> Future and Past meeting information: http://LCTG.toku.us
> This message was sent to s+lctglist at smistuff.com.
> Set your list options:
> http://lists.toku.us/options.cgi/lctg-toku.us/s+lctglist@smistuff.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.toku.us/private.cgi/lctg-toku.us/attachments/20200322/0a4ace06/attachment.html>


More information about the LCTG mailing list