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

Kenneth Cutter ken at kencutter.com
Sun Mar 22 09:11:32 PDT 2020


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 [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
> 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 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?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 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
> 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
> >>>> 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 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
> > 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
> 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
> ***********************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.toku.us/private.cgi/lctg-toku.us/attachments/20200322/ccee4175/attachment.html>


More information about the LCTG mailing list