Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.comp.software.thunderbird > #20992 > unrolled thread
| Started by | "John C." <r9jmg0@yahoo.com> |
|---|---|
| First post | 2026-06-22 02:46 -0700 |
| Last post | 2026-06-24 14:51 +0800 |
| Articles | 7 on this page of 47 — 9 participants |
Back to article view | Back to alt.comp.software.thunderbird
Slow message send "John C." <r9jmg0@yahoo.com> - 2026-06-22 02:46 -0700
Re: Slow message send "John C." <r9jmg0@yahoo.com> - 2026-06-22 02:47 -0700
Re: Slow message send Andy Burns <usenet@andyburns.uk> - 2026-06-22 11:04 +0100
Re: Slow message send "John C." <r9jmg0@yahoo.com> - 2026-06-23 06:31 -0700
Re: Slow message send "Carlos E. R." <robin_listas@es.invalid> - 2026-06-23 19:23 +0200
Re: Slow message send "John C." <r9jmg0@yahoo.com> - 2026-06-24 04:34 -0700
Re: Slow message send "Alan K." <alan@invalid.com> - 2026-06-22 07:28 -0400
Re: Slow message send "John C." <r9jmg0@yahoo.com> - 2026-06-23 06:53 -0700
Re: Slow message send VanguardLH <V@nguard.LH> - 2026-06-22 12:01 -0500
Re: Slow message send "John C." <r9jmg0@yahoo.com> - 2026-06-23 07:18 -0700
Re: Slow message send "John C." <r9jmg0@yahoo.com> - 2026-06-23 07:20 -0700
Re: Slow message send VanguardLH <V@nguard.LH> - 2026-06-23 12:34 -0500
Re: Slow message send "John C." <r9jmg0@yahoo.com> - 2026-06-24 05:38 -0700
Re: Slow message send VanguardLH <V@nguard.LH> - 2026-06-24 17:18 -0500
Re: Slow message send VanguardLH <V@nguard.LH> - 2026-06-23 12:02 -0500
Re: Slow message send "John C." <r9jmg0@yahoo.com> - 2026-06-24 05:48 -0700
Re: Slow message send Nobody <jock@soccer.com> - 2026-06-24 09:10 -0700
Re: Slow message send "John C." <r9jmg0@yahoo.com> - 2026-06-25 05:20 -0700
Re: Slow message send Nobody <jock@soccer.com> - 2026-06-25 09:15 -0700
Re: Slow message send "John C." <r9jmg0@yahoo.com> - 2026-06-26 06:24 -0700
Re: Slow message send Nobody <jock@soccer.com> - 2026-06-26 11:46 -0700
Re: Slow message send Paul <nospam@needed.invalid> - 2026-06-26 22:45 -0400
Re: Slow message send Nobody <jock@soccer.com> - 2026-06-27 11:27 -0700
Re: Slow message send Paul <nospam@needed.invalid> - 2026-06-26 22:50 -0400
Re: Slow message send VanguardLH <V@nguard.LH> - 2026-06-26 23:44 -0500
Re: Slow message send Paul <nospam@needed.invalid> - 2026-06-27 06:59 -0400
Re: Slow message send "Carlos E. R." <robin_listas@es.invalid> - 2026-06-27 14:09 +0200
Re: Slow message send Paul <nospam@needed.invalid> - 2026-06-27 10:33 -0400
Re: Slow message send "John C." <r9jmg0@yahoo.com> - 2026-06-28 00:55 -0700
Re: Slow message send VanguardLH <V@nguard.LH> - 2026-06-24 17:15 -0500
Re: Slow message send "John C." <r9jmg0@yahoo.com> - 2026-06-25 05:21 -0700
Re: Slow message send Frank Miller <miller@posteo.ee> - 2026-06-22 19:44 +0200
Re: Slow message send Andy Burns <usenet@andyburns.uk> - 2026-06-22 19:03 +0100
Re: Slow message send Frank Miller <miller@posteo.ee> - 2026-06-22 20:15 +0200
Re: Slow message send Nobody <jock@soccer.com> - 2026-06-22 12:01 -0700
Re: Slow message send "Carlos E. R." <robin_listas@es.invalid> - 2026-06-22 21:31 +0200
Re: Slow message send "John C." <r9jmg0@yahoo.com> - 2026-06-23 07:22 -0700
Re: Slow message send "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2026-06-23 22:34 +0800
Re: Slow message send Paul <nospam@needed.invalid> - 2026-06-25 09:38 -0400
Re: Slow message send Paul <nospam@needed.invalid> - 2026-06-25 10:28 -0400
Re: Slow message send Paul <nospam@needed.invalid> - 2026-06-25 11:45 -0400
Re: Slow message send "John C." <r9jmg0@yahoo.com> - 2026-06-26 06:28 -0700
Re: Slow message send "John C." <r9jmg0@yahoo.com> - 2026-06-26 06:28 -0700
Re: Slow message send Paul <nospam@needed.invalid> - 2026-06-26 09:56 -0400
Re: Slow message send "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2026-06-23 22:34 +0800
Re: Slow message send "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2026-06-23 03:13 +0800
Re: Slow message send "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2026-06-24 14:51 +0800
Page 3 of 3 — ← Prev page 1 2 [3]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2026-06-25 11:45 -0400 |
| Message-ID | <111jie3$3st08$1@dont-email.me> |
| In reply to | #21113 |
On Thu, 6/25/2026 10:28 AM, Paul wrote: > On 6/25/2026 9:38 AM, Paul wrote: >> On 6/23/2026 10:22 AM, John C. wrote: >>> Nobody wrote: >>>> Frank Miller wrote: >>>>> Andy Burns wrote: >>>>>> Frank Miller wrote: >>>>>>> >>>>>>> What the heck is "assembled" there? >>>>>> >>>>>> Bolting the headers, body and attachments together. >>>>> >>>>> I've never seen a message of that kind. >>>> >>>> It's been happening/appearing regularly for me for several versions of >>>> TB; I can't put a time-frame/version number on it. It's momentary and >>>> personally of no concern. >>> >>> For me, the delay is from around 5 seconds to as high as 10 (observed) >>> and maybe even longer. >>> >>> That's simply unacceptable to me. >>> >> >> So I suppose I should try a send into this group with TB 152.0 . >> >> I have my video recorder running, and my Wireshark running. > > From clicking "Sent" to complete, is around 5 seconds. > > Ryzen 5700G 8C 16T , lots of RAM, > Win10 x86 in VBox, 3072MB RAM, TB152.0 x86 installed. > > Unfortunately, the timestamp in Wireshark was not set to real time, > so I lost my correlation... > > <indeterminate text prep time> > 141.27 to 142.14 seconds > AUTHINFO user xxxxxxxx > AUTHINFO pass yyyyyyyy > 281 Authentication succeeded > 142.14 > POST > 340 OK recommended Message-ID <111jb19$3q87m$1@dont-email.me> > <Burst of one-sentence-per-packet > 142.2870 - 142.2930 42 packets in 0.006 seconds > > > <Burst of ACKS > 142.4125 - 142.4568 21 ACKS in 0.0443 seconds > > > 143.49 > 240 Article Received > > About 2.2 seconds on the wire, using a fairly inefficient > transmission scheme. Perhaps sending one line per packet > is some sort of goofy RFC ? > > So now we have to figure out where the rest of the time went. > I'll time this one on the way out. > > Paul Imagine a stopwatch is running. Some of the time mentioned here is "seconds after the top tick on the stop watch". The transaction starts at 11 seconds on the stop watch and ends at 18 seconds on the stop watch. The longer message took from 11 seconds to 18 seconds, for 7 seconds elapsed. Around 16-17.5 seconds is the network phase. Because I was careful to authenticate before posting, it did not need to authenticate before the POST request. At 17.5 seconds it did 240 Article Received. OK, that leaves 11-16 for textual preparation. Procmon tells me that at 13 seconds, there is the thunder of hoofbeats as "Avalon Graphics" are called. In the VBOX video recording, the graphics box appears at 16 seconds. This means "assembling" might actually correlate better with the wire phase of the thing. For procmon, there is radio silence up to 13 seconds, nothing (as usual) to tell me when I clicked. Procmon is not Windbg, and only a limited set of events are recorded. At 16.1 seconds, C:\users\bullwinkle\AppData\Local\Temp\nsemail.eml 2386 byte write so the message preparation is hidden somewhere else even more temporary than that. Whether the text is "gathered" before the 13 second mark, or some time between 13 and 16, I cannot determine as there are no marks. So that is the file which will eventually make it to the wire. At 16.16 seconds, that's when the POST packet is sent for the wire phase of the operation. And roughly around that same time point, the captured video of the VM claims the status box pops out. It's possible that the "baggage" of calling Avalon Graphics is having a high impact. Maybe in threading-land, they should have "warmed up" the Avalon Graphics at 11 seconds, even if there was no status to write to it at that point. I would guess a craftsman could optimize this a tiny bit, or, just dump the status box. I don't have any evidence to convince a jury. I can't see everything using three tools, and that's about all I can describe of what happens. I consider it a bit weird, that a message is sent, with a packet per sentence (when a packet could be as big as 1500 bytes). When I've seen black hole routing problems caused by my other email tool sending 1500 byte packets. But sending the small packets, does not cost anything for messages this small. It would not be a good way to send a 20MB email :-) Paul
[toc] | [prev] | [next] | [standalone]
| From | "John C." <r9jmg0@yahoo.com> |
|---|---|
| Date | 2026-06-26 06:28 -0700 |
| Message-ID | <111lup3$ibtj$1@dont-email.me> |
| In reply to | #21115 |
On 26/06/25 08:45 AM, Paul wrote: > On Thu, 6/25/2026 10:28 AM, Paul wrote: >> On 6/25/2026 9:38 AM, Paul wrote: >>> On 6/23/2026 10:22 AM, John C. wrote: >>>> Nobody wrote: >>>>> Frank Miller wrote: >>>>>> Andy Burns wrote: >>>>>>> Frank Miller wrote: >>>>>>>> >>>>>>>> What the heck is "assembled" there? >>>>>>> >>>>>>> Bolting the headers, body and attachments together. >>>>>> >>>>>> I've never seen a message of that kind. >>>>> >>>>> It's been happening/appearing regularly for me for several versions of >>>>> TB; I can't put a time-frame/version number on it. It's momentary and >>>>> personally of no concern. >>>> >>>> For me, the delay is from around 5 seconds to as high as 10 (observed) >>>> and maybe even longer. >>>> >>>> That's simply unacceptable to me. >>>> >>> >>> So I suppose I should try a send into this group with TB 152.0 . >>> >>> I have my video recorder running, and my Wireshark running. >> >> From clicking "Sent" to complete, is around 5 seconds. >> >> Ryzen 5700G 8C 16T , lots of RAM, >> Win10 x86 in VBox, 3072MB RAM, TB152.0 x86 installed. >> >> Unfortunately, the timestamp in Wireshark was not set to real time, >> so I lost my correlation... >> >> <indeterminate text prep time> >> 141.27 to 142.14 seconds >> AUTHINFO user xxxxxxxx >> AUTHINFO pass yyyyyyyy >> 281 Authentication succeeded >> 142.14 >> POST >> 340 OK recommended Message-ID <111jb19$3q87m$1@dont-email.me> >> <Burst of one-sentence-per-packet >> 142.2870 - 142.2930 42 packets in 0.006 seconds >> > >> <Burst of ACKS >> 142.4125 - 142.4568 21 ACKS in 0.0443 seconds >> > >> 143.49 >> 240 Article Received >> >> About 2.2 seconds on the wire, using a fairly inefficient >> transmission scheme. Perhaps sending one line per packet >> is some sort of goofy RFC ? >> >> So now we have to figure out where the rest of the time went. >> I'll time this one on the way out. >> >> Paul > > Imagine a stopwatch is running. Some of the time mentioned > here is "seconds after the top tick on the stop watch". > The transaction starts at 11 seconds on the stop watch and > ends at 18 seconds on the stop watch. > > The longer message took from 11 seconds to 18 seconds, for 7 seconds elapsed. > > Around 16-17.5 seconds is the network phase. > Because I was careful to authenticate before posting, > it did not need to authenticate before the POST request. > At 17.5 seconds it did 240 Article Received. > > OK, that leaves 11-16 for textual preparation. > > Procmon tells me that at 13 seconds, there is the > thunder of hoofbeats as "Avalon Graphics" are called. > In the VBOX video recording, the graphics box appears at 16 seconds. > This means "assembling" might actually correlate better with > the wire phase of the thing. > > For procmon, there is radio silence up to 13 seconds, nothing (as usual) > to tell me when I clicked. Procmon is not Windbg, and > only a limited set of events are recorded. > > At 16.1 seconds, > > C:\users\bullwinkle\AppData\Local\Temp\nsemail.eml 2386 byte write > > so the message preparation is hidden somewhere else even > more temporary than that. Whether the text is "gathered" > before the 13 second mark, or some time between 13 and 16, > I cannot determine as there are no marks. > > So that is the file which will eventually make it to the wire. > At 16.16 seconds, that's when the POST packet is sent for the > wire phase of the operation. And roughly around that > same time point, the captured video of the VM claims > the status box pops out. > > It's possible that the "baggage" of calling > Avalon Graphics is having a high impact. Maybe in > threading-land, they should have "warmed up" the > Avalon Graphics at 11 seconds, even if there > was no status to write to it at that point. > > I would guess a craftsman could optimize this a tiny > bit, or, just dump the status box. > > I don't have any evidence to convince a jury. I can't > see everything using three tools, and that's about > all I can describe of what happens. > > I consider it a bit weird, that a message is sent, with > a packet per sentence (when a packet could be as big > as 1500 bytes). When I've seen black hole routing problems > caused by my other email tool sending 1500 byte packets. > But sending the small packets, does not cost anything > for messages this small. It would not be a good way to > send a 20MB email :-) Thanks for all this info, Paul. Very interesting. Strange thing is that this morning, several of my messages have sent very quickly. -- John C. I filter crossposts, various trolls & dizum.com. Doing this makes this newsgroup easier to read & more on-topic. Take back the tech companies from India & industry from China.
[toc] | [prev] | [next] | [standalone]
| From | "John C." <r9jmg0@yahoo.com> |
|---|---|
| Date | 2026-06-26 06:28 -0700 |
| Message-ID | <111luqb$ic11$1@dont-email.me> |
| In reply to | #21126 |
On 26/06/26 06:28 AM, John C. wrote: > On 26/06/25 08:45 AM, Paul wrote: >> On Thu, 6/25/2026 10:28 AM, Paul wrote: >>> On 6/25/2026 9:38 AM, Paul wrote: >>>> On 6/23/2026 10:22 AM, John C. wrote: >>>>> Nobody wrote: >>>>>> Frank Miller wrote: >>>>>>> Andy Burns wrote: >>>>>>>> Frank Miller wrote: >>>>>>>>> >>>>>>>>> What the heck is "assembled" there? >>>>>>>> >>>>>>>> Bolting the headers, body and attachments together. >>>>>>> >>>>>>> I've never seen a message of that kind. >>>>>> >>>>>> It's been happening/appearing regularly for me for several versions of >>>>>> TB; I can't put a time-frame/version number on it. It's momentary and >>>>>> personally of no concern. >>>>> >>>>> For me, the delay is from around 5 seconds to as high as 10 (observed) >>>>> and maybe even longer. >>>>> >>>>> That's simply unacceptable to me. >>>>> >>>> >>>> So I suppose I should try a send into this group with TB 152.0 . >>>> >>>> I have my video recorder running, and my Wireshark running. >>> >>> From clicking "Sent" to complete, is around 5 seconds. >>> >>> Ryzen 5700G 8C 16T , lots of RAM, >>> Win10 x86 in VBox, 3072MB RAM, TB152.0 x86 installed. >>> >>> Unfortunately, the timestamp in Wireshark was not set to real time, >>> so I lost my correlation... >>> >>> <indeterminate text prep time> >>> 141.27 to 142.14 seconds >>> AUTHINFO user xxxxxxxx >>> AUTHINFO pass yyyyyyyy >>> 281 Authentication succeeded >>> 142.14 >>> POST >>> 340 OK recommended Message-ID <111jb19$3q87m$1@dont-email.me> >>> <Burst of one-sentence-per-packet >>> 142.2870 - 142.2930 42 packets in 0.006 seconds >>> > >>> <Burst of ACKS >>> 142.4125 - 142.4568 21 ACKS in 0.0443 seconds >>> > >>> 143.49 >>> 240 Article Received >>> >>> About 2.2 seconds on the wire, using a fairly inefficient >>> transmission scheme. Perhaps sending one line per packet >>> is some sort of goofy RFC ? >>> >>> So now we have to figure out where the rest of the time went. >>> I'll time this one on the way out. >>> >>> Paul >> >> Imagine a stopwatch is running. Some of the time mentioned >> here is "seconds after the top tick on the stop watch". >> The transaction starts at 11 seconds on the stop watch and >> ends at 18 seconds on the stop watch. >> >> The longer message took from 11 seconds to 18 seconds, for 7 seconds elapsed. >> >> Around 16-17.5 seconds is the network phase. >> Because I was careful to authenticate before posting, >> it did not need to authenticate before the POST request. >> At 17.5 seconds it did 240 Article Received. >> >> OK, that leaves 11-16 for textual preparation. >> >> Procmon tells me that at 13 seconds, there is the >> thunder of hoofbeats as "Avalon Graphics" are called. >> In the VBOX video recording, the graphics box appears at 16 seconds. >> This means "assembling" might actually correlate better with >> the wire phase of the thing. >> >> For procmon, there is radio silence up to 13 seconds, nothing (as usual) >> to tell me when I clicked. Procmon is not Windbg, and >> only a limited set of events are recorded. >> >> At 16.1 seconds, >> >> C:\users\bullwinkle\AppData\Local\Temp\nsemail.eml 2386 byte write >> >> so the message preparation is hidden somewhere else even >> more temporary than that. Whether the text is "gathered" >> before the 13 second mark, or some time between 13 and 16, >> I cannot determine as there are no marks. >> >> So that is the file which will eventually make it to the wire. >> At 16.16 seconds, that's when the POST packet is sent for the >> wire phase of the operation. And roughly around that >> same time point, the captured video of the VM claims >> the status box pops out. >> >> It's possible that the "baggage" of calling >> Avalon Graphics is having a high impact. Maybe in >> threading-land, they should have "warmed up" the >> Avalon Graphics at 11 seconds, even if there >> was no status to write to it at that point. >> >> I would guess a craftsman could optimize this a tiny >> bit, or, just dump the status box. >> >> I don't have any evidence to convince a jury. I can't >> see everything using three tools, and that's about >> all I can describe of what happens. >> >> I consider it a bit weird, that a message is sent, with >> a packet per sentence (when a packet could be as big >> as 1500 bytes). When I've seen black hole routing problems >> caused by my other email tool sending 1500 byte packets. >> But sending the small packets, does not cost anything >> for messages this small. It would not be a good way to >> send a 20MB email :-) > > Thanks for all this info, Paul. Very interesting. > > Strange thing is that this morning, several of my messages have sent > very quickly. But not this last one. It took around 6 seconds to "assemble and send". -- John C. No ad, CD, cripple, demo, nag, pay, pirated, share, spy, time-limited, trial or web wares for me please. I filter crossposts, various trolls & dizum.com. This makes ACF easier to read. Take back tech corporations from India & industry back from China.
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2026-06-26 09:56 -0400 |
| Message-ID | <111m0f6$it7f$1@dont-email.me> |
| In reply to | #21127 |
On Fri, 6/26/2026 9:28 AM, John C. wrote: > On 26/06/26 06:28 AM, John C. wrote: >> On 26/06/25 08:45 AM, Paul wrote: >>> On Thu, 6/25/2026 10:28 AM, Paul wrote: >>>> On 6/25/2026 9:38 AM, Paul wrote: >>>>> On 6/23/2026 10:22 AM, John C. wrote: >>>>>> Nobody wrote: >>>>>>> Frank Miller wrote: >>>>>>>> Andy Burns wrote: >>>>>>>>> Frank Miller wrote: >>>>>>>>>> >>>>>>>>>> What the heck is "assembled" there? >>>>>>>>> >>>>>>>>> Bolting the headers, body and attachments together. >>>>>>>> >>>>>>>> I've never seen a message of that kind. >>>>>>> >>>>>>> It's been happening/appearing regularly for me for several versions of >>>>>>> TB; I can't put a time-frame/version number on it. It's momentary and >>>>>>> personally of no concern. >>>>>> >>>>>> For me, the delay is from around 5 seconds to as high as 10 (observed) >>>>>> and maybe even longer. >>>>>> >>>>>> That's simply unacceptable to me. >>>>>> >>>>> >>>>> So I suppose I should try a send into this group with TB 152.0 . >>>>> >>>>> I have my video recorder running, and my Wireshark running. >>>> >>>> From clicking "Sent" to complete, is around 5 seconds. >>>> >>>> Ryzen 5700G 8C 16T , lots of RAM, >>>> Win10 x86 in VBox, 3072MB RAM, TB152.0 x86 installed. >>>> >>>> Unfortunately, the timestamp in Wireshark was not set to real time, >>>> so I lost my correlation... >>>> >>>> <indeterminate text prep time> >>>> 141.27 to 142.14 seconds >>>> AUTHINFO user xxxxxxxx >>>> AUTHINFO pass yyyyyyyy >>>> 281 Authentication succeeded >>>> 142.14 >>>> POST >>>> 340 OK recommended Message-ID <111jb19$3q87m$1@dont-email.me> >>>> <Burst of one-sentence-per-packet >>>> 142.2870 - 142.2930 42 packets in 0.006 seconds >>>> > >>>> <Burst of ACKS >>>> 142.4125 - 142.4568 21 ACKS in 0.0443 seconds >>>> > >>>> 143.49 >>>> 240 Article Received >>>> >>>> About 2.2 seconds on the wire, using a fairly inefficient >>>> transmission scheme. Perhaps sending one line per packet >>>> is some sort of goofy RFC ? >>>> >>>> So now we have to figure out where the rest of the time went. >>>> I'll time this one on the way out. >>>> >>>> Paul >>> >>> Imagine a stopwatch is running. Some of the time mentioned >>> here is "seconds after the top tick on the stop watch". >>> The transaction starts at 11 seconds on the stop watch and >>> ends at 18 seconds on the stop watch. >>> >>> The longer message took from 11 seconds to 18 seconds, for 7 seconds elapsed. >>> >>> Around 16-17.5 seconds is the network phase. >>> Because I was careful to authenticate before posting, >>> it did not need to authenticate before the POST request. >>> At 17.5 seconds it did 240 Article Received. >>> >>> OK, that leaves 11-16 for textual preparation. >>> >>> Procmon tells me that at 13 seconds, there is the >>> thunder of hoofbeats as "Avalon Graphics" are called. >>> In the VBOX video recording, the graphics box appears at 16 seconds. >>> This means "assembling" might actually correlate better with >>> the wire phase of the thing. >>> >>> For procmon, there is radio silence up to 13 seconds, nothing (as usual) >>> to tell me when I clicked. Procmon is not Windbg, and >>> only a limited set of events are recorded. >>> >>> At 16.1 seconds, >>> >>> C:\users\bullwinkle\AppData\Local\Temp\nsemail.eml 2386 byte write >>> >>> so the message preparation is hidden somewhere else even >>> more temporary than that. Whether the text is "gathered" >>> before the 13 second mark, or some time between 13 and 16, >>> I cannot determine as there are no marks. >>> >>> So that is the file which will eventually make it to the wire. >>> At 16.16 seconds, that's when the POST packet is sent for the >>> wire phase of the operation. And roughly around that >>> same time point, the captured video of the VM claims >>> the status box pops out. >>> >>> It's possible that the "baggage" of calling >>> Avalon Graphics is having a high impact. Maybe in >>> threading-land, they should have "warmed up" the >>> Avalon Graphics at 11 seconds, even if there >>> was no status to write to it at that point. >>> >>> I would guess a craftsman could optimize this a tiny >>> bit, or, just dump the status box. >>> >>> I don't have any evidence to convince a jury. I can't >>> see everything using three tools, and that's about >>> all I can describe of what happens. >>> >>> I consider it a bit weird, that a message is sent, with >>> a packet per sentence (when a packet could be as big >>> as 1500 bytes). When I've seen black hole routing problems >>> caused by my other email tool sending 1500 byte packets. >>> But sending the small packets, does not cost anything >>> for messages this small. It would not be a good way to >>> send a 20MB email :-) >> >> Thanks for all this info, Paul. Very interesting. >> >> Strange thing is that this morning, several of my messages have sent >> very quickly. > > But not this last one. It took around 6 seconds to "assemble and send". > It adds only a tiny increment of time, to re-authenticate and then do the POST and packet-per-sentence thing. The time to prepare the nsemail file, seems a bit excessive. Authentication has been busted before, so it's not like authentication always happens instantly. But then your "time" would be a lot longer than 6 seconds, if that style of flaw at the server end was involved. Paul Paul
[toc] | [prev] | [next] | [standalone]
| From | "Mr. Man-wai Chang" <toylet.toylet@gmail.com> |
|---|---|
| Date | 2026-06-23 22:34 +0800 |
| Message-ID | <111e5ik$2adav$2@toylet.eternal-september.org> |
| In reply to | #21027 |
On 6/23/2026 3:01 AM, Nobody wrote:
>
> It's been happening/appearing regularly for me for several versions of
> TB; I can't put a time-frame/version number on it. It's momentary and
> personally of no concern.
Is this a setup to eliminate Thunderbird?
--
@~@ Simplicity is Beauty! Remain silent! Drink, Blink, Stretch!
/ v \ May the Force and farces be with you! Live long and prosper!!
/( _ )\ https://sites.google.com/site/changmw/
^ ^ https://github.com/changmw/changmw
[toc] | [prev] | [next] | [standalone]
| From | "Mr. Man-wai Chang" <toylet.toylet@gmail.com> |
|---|---|
| Date | 2026-06-23 03:13 +0800 |
| Message-ID | <111c1h5$1ok0v$1@toylet.eternal-september.org> |
| In reply to | #20992 |
On 6/22/2026 5:46 PM, John C. wrote:
>
> Now, however, when I send an email or post a message I get a message saying:
> ______________________________________________________________________
> Sending message - (message subject here) X
> Status: Assembling message...Done
> Progress:--------------------------------------------------------
I only got an error if the message could not be sent.
Are you using Mozilla Thunderbird? Are you really using it?
Or... Or...are you using sending mail inside a sealed game? :)
--
@~@ Simplicity is Beauty! Remain silent! Drink, Blink, Stretch!
/ v \ May the Force and farces be with you! Live long and prosper!!
/( _ )\ https://sites.google.com/site/changmw/
^ ^ https://github.com/changmw/changmw
[toc] | [prev] | [next] | [standalone]
| From | "Mr. Man-wai Chang" <toylet.toylet@gmail.com> |
|---|---|
| Date | 2026-06-24 14:51 +0800 |
| Message-ID | <111fuoo$2qdmi$2@toylet.eternal-september.org> |
| In reply to | #20992 |
On 6/22/2026 5:46 PM, John C. wrote:
>
> Now, however, when I send an email or post a message I get a message saying:
> ______________________________________________________________________
> Sending message - (message subject here) X
> Status: Assembling message...Done
> Progress:--------------------------------------------------------
> [Cancel]
> ______________________________________________________________________
Are you using a bogus Thunderbird? That is, a program that behaves,
looks and feels like Mozilla Thunderbird.
--
@~@ Simplicity is Beauty! Remain silent! Drink, Blink, Stretch!
/ v \ May the Force and farces be with you! Live long and prosper!!
/( _ )\ https://sites.google.com/site/changmw/
^ ^ https://github.com/changmw/changmw
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | alt.comp.software.thunderbird
csiph-web