Hi Björn,

On 27 Jan 16 14:46, Björn Felten wrote to Kees van Eeten:
about: "Compression in Binkd":

It does reduce the use of bandwith

I see absolutely no advantage with that. I have an abundance of bandwidth. Almost all connections is done within a second.

You said almost, but just last week I had a 3 hour binkd connection, that could
have been done 70x faster, with better compression! And that connection interfered with other (fido) processes. Compression is still very usefull in todays internet!

Wilfred.

--- FMail-W32-1.69.10.141-B20151003
* Origin: point@work (2:280/464.112)

last week I had a 3 hour binkd connection,

Well, I try to stay away from binkd transportation of stuff in the multi-gigabyte class. 8-)

--- Paul's Win98SE VirtualBox
* Origin: Quinn's Post - Maryborough, Queensland, OZ (3:640/384)

Hello Wilfred,

On Wednesday January 27 2016 08:35, you wrote to Björn Felten:

I see absolutely no advantage with that. I have an abundance
of bandwidth. Almost all connections is done within a second.

You said almost, but just last week I had a 3 hour binkd connection,
that could have been done 70x faster, with better compression! And
that connection interfered with other (fido) processes.

Yeah, it made a just in time, same as last week pointlist segment to be delivered five minutes late. Big deal.

Compression is still very usefull in todays internet!

It was a one time incident that is unlikely to ever be repeated in that way. One does not base policy on a one time, never to be repeated incident.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20130111
* Origin: http://www.vlist.eu (2:280/5555)

Hi,

On 2016-01-27 17:11:46, Michiel van der Vlist wrote to Wilfred van Velzen:
about: "Compression in Binkd":

You said almost, but just last week I had a 3 hour binkd connection,
that could have been done 70x faster, with better compression! And
that connection interfered with other (fido) processes.

MvdV> Yeah, it made a just in time, same as last week pointlist segment to be
MvdV> delivered five minutes late.

... And it missed the deadline.

Bandwith is still a limited resource and more expensive than computer cycles. Afaik data transfer is still metered by the byte on the peering level. So you might not pay for it directly. But it probably makes a difference how much data
is transfered by all their customers combined, what internet providers will have to charge as monthly subscription rate...

Bye, Wilfred.


--- FMail-W32-1.69.12.144-B20160109
* Origin: Native IPv6 connectable node (2:280/464)

Hello Wilfred,

On Wednesday January 27 2016 18:39, you wrote to me:

You said almost, but just last week I had a 3 hour binkd
connection, that could have been done 70x faster, with better
compression! And that connection interfered with other (fido)
processes.

MvdV>> Yeah, it made a just in time, same as last week pointlist
MvdV>> segment to be delivered five minutes late.

... And it missed the deadline.

Big deal since it was the same as last week's...

Bandwith is still a limited resource and more expensive than computer cycles. Afaik data transfer is still metered by the byte on the
peering level. So you might not pay for it directly. But it probably
makes a difference how much data is transfered by all their customers combined, what internet providers will have to charge as monthly subscription rate...

True, but the traffic generated by fidonet is neglegible compared to all the other traffic.

Also I wonder if binkd compression would have made any difference in the incident you metioned. I send a large compressed file, but made an unlucky choice for the compressor. Could the binkd compression have compensated for that? Maybe, but it would not have, since it is configured to not try to compress already compressed files.

As I said before, this was just a one time incident that will not be repeated. Next time I send such a file, I will use a better compressor. One does not base
a policy on a one time incident that will in all likehood never repeat.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20130111
* Origin: http://www.vlist.eu (2:280/5555)

Hi Michiel,

On 27 Jan 16 22:43, Michiel van der Vlist wrote to Wilfred van Velzen:
about: "Compression in Binkd":

MvdV>>> Yeah, it made a just in time, same as last week pointlist
MvdV>>> segment to be delivered five minutes late.

... And it missed the deadline.

MvdV> Big deal since it was the same as last week's...

That's not important, it could have mattered!

Bandwith is still a limited resource and more expensive than computer
cycles. Afaik data transfer is still metered by the byte on the
peering level. So you might not pay for it directly. But it probably
makes a difference how much data is transfered by all their customers
combined, what internet providers will have to charge as monthly
subscription rate...

MvdV> True, but the traffic generated by fidonet is neglegible compared to all
MvdV> the other traffic.

That's like saying your not going to vote because your single vote wouldn't change the outcome of an election. That's "true" also...

MvdV> Also I wonder if binkd compression would have made any difference in
MvdV> the incident you metioned. I send a large compressed file, but made
MvdV> an unlucky choice for the compressor. Could the binkd compression
MvdV> have compensated for that? Maybe, but it would not have, since it is
MvdV> configured to not try to compress already compressed files.

It might have made a difference if you didn't compress it all, but not nearly as much as the 70x that 7zip improved on it. But your current mingw version of binkd only supports zip compression not bzip2 compression, so than it wouldn't have mattered...

Wilfred.

--- FMail-W32-1.69.10.141-B20151003
* Origin: point@work (2:280/464.112)