Subj : zip and unzip
To   : Dallas Hinton
From : mark lewis
Date : Mon Aug 06 2018 09:21 pm


On 2018 Aug 06 16:30:52, you wrote to Benny Pedersen:

BP>> no it really is that simple, ask the sender to not pack if he cant
BP>> use updated software

DH> It's an option, of course - and given the size (small) of today's
DH> packets, not much implication for bandwidth. It just goes against the
DH> grain! :-)

i just can't justify the CPU wastage... especially when looking at stats like
this...


           Echomail Statistics for the period of

      01 Aug 18, 00:20:07      -     05 Aug 18, 23:48:09


                   Inbound packets : 50602


we're only five(!) days into the month and there's already been 50000+ PKTs
dropped off here :shock: they come in every few minutes... i've seen some
systems dropping off packets here within a minute of their last connection...
sometimes a connection will drop off two or three PKTs at once and then do it
again a few seconds later with new PKTs but hey, folks want near-real-time
conversations so...

so anyway, consider if that was 50000 zipped mail bundles... the time to zip
and unzip them is much better used for something else... add to that that some
mailers can compress data on the fly when transmitting it just like web servers
do... i just... i don't know, man... mail bundles were created to solve a
problem FTNs had a long long time ago... that problem was transmission time...
a problem that is non-existant (for the most part) these days... it takes two
steps right out of the processing loops and reducing the number of steps needed
is generally a GoodThing<tm> ;)



just for the heck of it, here's last months inbound stat...


           Echomail Statistics for the period of

      01 Jul 18, 00:17:54      -     31 Jul 18, 23:48:17


                   Inbound packets : 274214




)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it
wrong...
... We come UNARMED...... this time!
---
* Origin:  (1:3634/12.73)